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Abstract 

In this article we discuss the problem of global 
illumination. We discuss various observations 
of the problem to explore new approaches of 
solving it. Then we take thees observations 
and derive a number of practical examples how 
global illumination can be emulated in real- 
time rendering engines that can run on cur- 
rent level of hardware. The article discusses 
everything from simple minor changes to more 
drastic designs, but all are designed to fit in to 
existing technology. 

Observations 

In order to reach our goal we should first make 
a few observations about our problem. This 
will form the basis for a "tool box" of tech- 
niques that can be used to improve graphic en- 
gines. 

It can’t be done 

If we consider the vast amount of photons that 
leaves even the most tiny of light sources, and 
how each photon can in theory bounce an in- 
finite number of times against surfaces, and 
then the likelihood of hitting the tiny surface 
that is your retina, we quickly realize that no 
computer is even remotely close being able to 
simulate reality. So we can stop looking for 
that next generation CPU, graphics processor 
or feature. There is no silver bullet. 


This however gives us the right to cheat. 
Even people who write off-line rendering en- 
gines cheat, so why shoulden’t the real-time 
community cheat? This also states that any- 
thing is fair game as long as the result looks 
good. Actually global illumination is all about 
getting away with cheating. This is where the 
fun begins. 

Please define real-time 

If you ask people to define real-time you get 
many different answers. A him person may say 
24fps, while an arcade person may say GOfps, 
and a professional player may not be satisfied 
until the frame rate is way above lOOfps. In 
reality this is because different parts of the 
brain have different priority. Motion detection 
is very fast and that is why the professional 
player needs above lOOfps to be able to dodge 
that incoming rocket (the need for fast motion 
feedback is obviously also influenced by the 1.5 
frame latency that all engines have). Detect- 
ing colors are also fast, but recognizing shapes 
and images are considerably slower. Although 
modern people are trained in picking up fast 
cuts, around lOfps is probably the limit. 

Global illumination has a very low priority, 
and may not need updating very often. My 
experience is that many things in a game en- 
gine do not have to be updated every frame. 
For instance AI doesnt have to be computed 
every frame. (Often this can result in better 
behaving AI. If a grenade is thrown in to a 
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group of enemies it looks unrealistic when all 
enemies simultaneously turn since they all real- 
ized the treat at the same time). My suggestion 
is that one build a "kernel" that can let differ- 
ent tasks have different priority and by doing 
this only update the most crucial parts of the 
simulation. Therefore whenever even precom- 
putation is mentioned it may mean "computa- 
tion stretched out over a longer time then one 
frame". 

The error allowed is huge 

If we consider that ambient light only con- 
tribute a small portion of light to each surface, 
and that each surface point is influenced by a 
full hemisphere, we come to the conclusion that 
the influence of an object in the environment is 
very limited. Let us consider this: If we assume 
that an objects surface has about 30 

The ideal size of a primitive is one 
pixel 

In the Siggraph paper "The Reyes image ren- 
dering architecture" form 1987, researchers at 
Pixar claimed that each primitive (in their case 
a quadrillion) should be proportional in size to 
the pixels that render them. (In their case a 
half a pixel due to anti aliasing). The point was 
that anything larger would look bad, and any- 
thing smaller would be redundant. This makes 
things very interesting for global illumination 
since the pixels are so very large. A 1920 * 1080 
image rendered by a camera viewing 90 degree 
horizontally, gives a pixel angle of 0,046875 de- 
grees. This means that in a distance of one 
meter the ideal size of a primitive is 0.8 mil- 
limeter. When rendering an environment hemi- 
sphere for the purpose of global illumination it 
may be equal to a 8*8 image spanning 180 de- 
grees, is gives each pixel 22.5 degree span and 
a primitive at one meters distance should be as 
large as 39 centimeters! 


This means that a 180 centimeter long (and 
preferably 180 centimeters wide) person at the 
distance of 4.6 meters can be replaced by a sin- 
gle primitive. This tells us something of the 
extrema coursness that we can use and how 
simple our data sets really can be. 

In what direction does light travel? 

Obviously from the light source via surfaces 
and then in to your eye, but that is in reality. 
Ray tracing usually goes the opposite direction. 
This has some obvious benefits as you can dis- 
regard all rays of light that doesn’t hit your eye. 
However if that ray bounces around a room it 
is very unlikely to hit the tiny light bulb hang- 
ing from the ceiling, so you are back to the 
same problem again. This is why it is com- 
mon for ray tracing renderers always direct the 
rays directly toward the light sources once thy 
have bounded around the geometry. The en- 
gine knows that some objects are light sources 
and that they are important light contribu- 
tors. This makes stocastic raytracers with in 
the realm of production speed rendering algo- 
rithms, but it does however create some prob- 
lems when dealing with effects like coustics, or 
an environment where many surfaces are light 
sources, or are not light sources but are so 
bright that they could be considerd as such. 

So what we can see here is that there is an 
enormous benefit to letting the engine know 
more about the environment, and go in differ- 
ent directions in different instances. By just 
dividing you the environment in two categories 
of lightsources and surfaces, we get significant 
performance improvements. What we should 
do is not just divide our environment up in two 
groups, but let all geometry and light sources 
be sorted and stored in such a way that we 
easely can find the light sources and/or surfaces 
that influence any point in the environment the 
most . 
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The world is a hierarchical BRDF 

A Bidirectional Reflectance Distribution Func- 
tion is basicly a function that computes how 
incoming light reflects of a particular surface. 
You could argue that it is an idea of a uni- 
versal way of describing materials. However 
one of the reasons why different surfaces be- 
have so drastically different is because of mi- 
cro geometry. Micro geometry is usually de- 
fined as geometry that is smaller then one pixel. 
This is geometry that is so small that mod- 
elling the world including this property would 
give us gigantic data sets, but they still mat- 
ter a great deal to how the surfaces appear. 
Torrence cook where early in defining shaders 
that where influenced by micro geometry, and 
in 2000 the Siggraph paper "Illuminating Mi- 
cro Geometry Based on Precomputed Visibil- 
ity" took the next step of actually computing 
a BRDF from geometry. 

So going back to the question of what micro 
geometry is, we can say that anything is mi- 
cro geometry if viewed from a proper distance. 
A 180 centimeter long person rendered at 4.6 
meters distance can be micro geometry, and 
therefor be defined as a BRDF. So we can use 
a BRDF as a primitive! A primitive that con- 
tains geometry and materials. We add size and 
position in the world and we have all we need. 
However we want the size of our primitive to be 
one pixel and therefore we make it hierarchical 
so that once we get closer to an object we can 
render it as multiple BRDFs. For games we can 
simply define the BRDFs computation as a dot 
product, modulated by color. 

Rembrandt could do it 

So we have concluded that this is a problem 
that no hardware can simulate properly. How 
is it that people like Rembrandt, Leonardo da 
Vinci, and Raphael could do it so well? They 
knew substantially less about how light works 


than we can teach computers, yet they are so 
good. Perhaps we should not try to copy na- 
ture and physics but rather try to copy the 
great masters. The truth is that we are not 
looking for realism, we are trying to make our 
brains fire the right synapses. Our visual sys- 
tem is constantly looking for clues to what the 
data our retinas collect really means and there 
are some special things that we look for and 
recognize. 

To prove this, render a sphere with a plain 
gray ambient color and place it in front of a 
plain white color. This looks totally unrealistic 
while it in fact is very realistic. In a completely 
evenly lit environment the ambient light of the 
sphere should be plain. But our brain refuses 
to believe that there are any evenly lit environ- 
ments, because it have never encountered one 
before so it seems kind of unlikely. If we now 
add a slight low frequency perlin noise it looks 
a lot better. Obviously the noise isn’t an accu- 
rate simulation of light but our brain recognizes 
the unevenness caused by environment lighting 
and thinks this image is more realistic. The 
brain can’t exactly determine what causes this 
and the exact influence of the environment, but 
it does recognize some effects such as contact 
shadows, shadows in cavities, and how environ- 
ments tend to get uniformed colorings. Thees 
effects can be copied to fool the brain that the 
light is behaving realistically. 

Pleasing the mind 

Finally and perhaps slightly off topic. We have 
to decide what our images are created for. As 
I am a strong believer in that computer games 
are an art form, artistic freedom must be given. 
So called Non photo realistic Tenderers or toon 
shaders have been used in some games, but 
them aside, I think its time for the "realistic" 
games to look into the possibilities. In todays 
film, commercial, and music video market a lot 
of tweaking is done in the post production. I 
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would advise any graphics programmer to visit 
a local post production facility and see what 
they do in terms of retouch, color correction 
and finishing. They highlight areas of interest, 
remove unwanted distractions and composite 
multiple shots. The importance of this step 
should not be underestimated, some even claim 
that the key to becoming a successful photog- 
rapher is to bribe his/her copier with love and 
alcohol. While the photographer decides the 
subject the post decides what you think of it. 

Practicalities 

So that is some theory. Let us kick of some sim- 
ple applications of these ideas, without making 
any major changes to the way an engine oper- 
ates. One obvious way one can do global illumi- 
nation is to precompute the global illumination 
per vertex or in a light map, this however has 
been done before and it requires all the geom- 
etry and lights to be static, so we are going to 
skip that and go straight to the next step of 
actually considering solutions where both the 
light sources and geometry are dynamic. How- 
ever I would like to point out that it may be 
a path worth exploring depending on the en- 
gine you are developing. Perhaps a hybrid en- 
gine where some parts of the light is precom- 
puted and others are computed by real time 
algorithms may be a good middle ground for 
your engine. 

Cavity shading 

The first we can do is to precompute the vis- 
ibility of each point on a surface (either per 
vertex or texel) to see how large part of the 
surfaces hemisphere is obstructed. This sim- 
ple technique is great for shading down cavities 
and are often done by texture artists by hand. 
To make this a little more sophisticated you 
can let the color of the obstructing geometry 


colorize the surface and weight the influence of 
the obstruction geometry by distance. 

Bended normals 

To light a surface we use normals. In a 
mathematical sense a 3d normal is a vector 
that is perpendicular to surface, but in com- 
puter graphics the normal usually represents 
the ideal direction of incoming light and that 
may not necessarily be the one and same. So 
what we can do is to bend the normals away 
from any obstructing geometry. This makes it 
possible to light the surface from a point below 
the plane of the surface. This is obviously im- 
possible if we consider only directional lighting, 
but if we consider indirect lighting it becomes 
possible because the incoming light bounces off 
the surrounding surfaces. If you have a flat sur- 
face and you tweak the normals just slightly 
away from the environment the surface will get 
a slightly uneven lighting and it will look a lot 
better. 

The great thing about these two approaches 
is that they fit very well with the way engines 
are traditionally written. All we need to do is 
change our input data. 

Pre-determined surface samples 

For static geometry like indoor environments 
with dynamic lights, there is an other good way 
of simulating global illumination. An offline 
global illumination renderer, based on stochas- 
tic raytracing sends out a number of rays to 
sample the environment, but in a static envi- 
ronment we can precompute and store surfaces 
in the environment to be used to light the sur- 
face in real time. 

If we want to compute how one surface in- 
fluence an other we need to know a few things 
about it. We need to know the position, the 
normal, and BRDF of the reflecting surface and 
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the distance and angle to the reserving surface. 
For games the BRDF can be computed as a 
dot product and a diffuse color. The distance 
and angle determines the brightness and can 
therefore be removed by modulating the color. 
So we can therefore optimize one surface influ- 
ence of an other as nine floating point values of 
data (position, normal and color). For a par- 
ticular point on a surface we can precalculate 
this influence of a set number of surfaces that 
are static in relation to the receiving surface. A 
light source that is introduced in this environ- 
ment can now be lit directly, and by a number 
of surrounding surfaces that influences it. A 
benefit to this approach is that the added light 
computations can be done in hardware. How 
many environment sample that can be taken 
in to consideration can dynamically be deter- 
mined by the capabilities of the hardware and, 
how much computing time is taken up by other 
things one might want to do in hardware such 
as advanced shaders and animation. Once this 
framework has been implemented it can also be 
used to simulate coustics and sub-surface scat- 
tering where also lighting from other directions 
then the surface normal influence the surface 
lighting. 

This algorithm requires some precomputa- 
tion to determine the most influential surfaces 
in the environment but it is still fairly straight 
forward. However it has one major problem. If 
your dynamic light source gets very close to the 
point of influence strange things may happen, 
because the actual influence doesn’t come from 
a point but from a larger surface. This can be 
fixed by adding a tenth value that determine 
a culling plane that is in front of the surface. 
By moving the position of the sample in the 
opposite direction of the normal in to the ob- 
ject, it will look good even if the light source 
comes very close to the surface. However, then 
the sample may even be lit if the light is on the 
other side of the surface. Therefore you need to 
store the distance the sample got moved back 


in order to cull out any light sources that are 
within the surface. The larger the surface is the 
further in you move the position of the sample 
back. This does require some extra computa- 
tion but it will remove some strange effects that 
you may otherwise experience. 

Neighbor lists 

In a complex world it can be good to be able to 
determine the most important neighbors. One 
algorithm that i frequently use is to store a list 
of neighbors in each object. To avoid using 
much CPU we use a inexact sorter, for each 
frame compare the furthest neighbor to a ran- 
domly selected object. If the object is closer, 
the furthest neighbor is replaced by the selected 
object. To make it even more efficient we can 
also compare it to a randomly selected neigh- 
bor of a neighbor. The list can have different 
weighting, that takes in to account, object size, 
brightness and other properties. Perhaps it it 
can be useful to have more then one list per 
object to store different types of neighboring 
objects. Having access to such list can be use- 
ful not just for graphics but for things like AI 
too. 

Once we have this data we can convert all 
surrounding objects to light sources. To com- 
pute how a neighbor lights an object, we start 
by lighting the neighbor by the light sources, 
in order to do this we need a normal and there 
are a few different ways one can be computed. 
The easiest one is to take the vector form the 
position of the neighbor and the position of 
the object. If each object has a precomputed 
BRDF that contains information on how it re- 
flects light in all directions this is fine, but if 
we use a simple dot product and a color it may 
look bad. In this case it is better to use a nor- 
mal that is the half angle between the vector 
from the neighbor position to the object posi- 
tion and the vector from the neighbor position 
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to the lightsource position. 

Now that we know how much light and what 
color each neighbor reflects toward the object. 
All we need to do is to place one light source 
with the computed color and brightness in each 
neighbor. 

Environment maps 

Most modern graphics hardware supports cu- 
bic environment maps and they can be very 
usefully for global illumination purposes. What 
we can do is to paint in objects into a small 
scale environment cube and use it as a direc- 
tional lookup table of the incoming light. If 
we paint in objects just as pixels, according 
to my tests the ideal size of such a environ- 
ment cube 6x6x6 pixels large. However most 
hardware tends to like the size 4x4x6 or 8x8x6 
pixels. 

The first thing you need is a temporary cube 
buffer where each pixel is represented as red, 
green, blue and z-depth. It is advisable to use 
floating point values for all these values to ob- 
tain high dynamic range (this will be discussed 
further later). First we fill this buffer with a 
background image. It can be a plain color, an 
image or a range that simulates a sky dome. 
This sky dome will greatly influence the look of 
the finished rendering so take your time tweak- 
ing it. It is actually so influential that you may 
dispense with the painting in of objects, but 
that would be a bit to boring for this article 
so we are going to go ahead and make it a bit 
more complicated. 

To paint in an object we just compute the 
incoming light of an object and draw a pixel of 
the color in the cube map pixel that represents 
the direction where the object can be found. 
With z-buffering we can create occlusion, by 
comparing the z-value to the previous z-value. 

The environment map we get here is not yet 
ready to be sent to the graphics card, because 


a surface in one direction doesn’t just get lit by 
the object that is in that direction but also by- 
all other objects in that hemisphere. Therefore 
wee need to "smooth" this environment map, 
and to smooth a pixel we add the sum of all 
pixels in the hemisphere modulated by a dot 
product. This makes the colors furthest away 
less influential. Finally we must divide the sum 
color with the sum of all dot products in the 
hemisphere. 

As you understand this final step is by far 
the slowest and that is why the choice of cube 
map size is such a crucial one. But once you 
have computed the finished environment map 
you can use it as many times as you want. 
You can split up the computation over a num- 
ber of frames, and update one object at the 
time to get the real time performance. Since 
all this computation is done in software, us- 
ing floating point values is fine. But once you 
get to the hardware you might not want to use 
HDRI since not all hardware supports it and it 
takes up more memory. But since you add the 
smoothing step any spikes of very bright spots 
are going to be flattened, so you will get away 
just fine with normal fixed point texture data. 

There is a rumor that says that radians 
doesn’t decay with distance and it is in part 
true. If you photograph a white sphere in a 
black room the sphere wont become darker the 
further away you are. However the sphere will 
become smaller, so average brightness of the 
image will diminish the further away you move. 
If you scatter random rays in an environment 
the radiance will be constant since we will as- 
sume that more rays will hit the object if it is 
closer. However if there are very few rays, or if 
we draw just one or very few pixels in an en- 
vironment, this wont be good enough. In this 
case we actually do modulate for distance and 
divide the brightness with the number of times 
the object is sampled. With this in mind it can 
be a good idea to draw an object as more than 
one pixel in an environment map to get better 
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occlusion. 

Final thoughts 

In conclusion i would like to encourage devel- 
opers and researchers to be less afraid to ex- 
plore new possibilities, even if they appear to 
be "hacks". By lowering the demand for qual- 
ity, we can explore alternative techniques that 
may in the end benefit even high quality ren- 
derings. 

In my opinion the key to solving the problem 
of global illumination (both in real-time and 
for off-line renderers) is to create alternative 
geometry representations for the light reflect- 
ing geometry. We need a new field of research 
to explore how to generate and store reflective 
properties of geometry. Hierarchical BRDFs is 
one such representation but there are probably 
many more. There have been much research in 
geometry complexity reduction while preserv- 
ing visual features such as edges and silhou- 
ettes. The same type of algorithms should be 
developed where the reflective properties are 
preserved. 
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